Existing behavior
Configuration or Deconfiguration is never attempted on admin down switching devices.
Target Devices
Devices on which the configuration is intended to be pushed.
Complete Failure Topology
- Topology having at least one
single-homed device in admin down state or atleast one dual-homed device
pair with both the devices in admin down state is a “complete failure
topology”.
- Any Tenant CLI or REST API of
create or delete nature attempted on the target devices having “complete
failure topology” is rejected with an appropriate error and result in a
complete failure. XCO does not have any configuration recipe prepared for
this REST API or CLI as the entire request is rejected. For example, an EPG
(endpoint group) create attempted on a single-homed device which is admin
down state.
Complete Success Topology
- Topology with all the
single-homed devices and all the dual-homed device pair in admin up state is
a “complete success topology”.
- Any Tenant CLI or REST API of
create or delete nature attempted on the target devices having “complete
success topology” results in the configuration recipe preparation for all
the target devices and the configuration is attempted on all the target
devices as all the target devices are in “admin up” state.
Partial Success Topology
- Topology which is not a “complete
failure topology” and have at least one dual-homed device pair with one of the
device in admin down state and the other device in admin up state is a “partial
success topology”.
- Any Tenant CLI or REST API of
create nature attempted on the target devices having “partial success topology”
will result in the configuration being attempted on the “admin up” devices and
configuration not being attempted on the “admin down” devices. Even though
configuration is not attempted for “admin down” devices, the configuration is
treated as success for the “admin down” devices.
Configuration recipe is
prepared and persisted in XCO for all the devices, and the configuration is
auto reconciled with the devices when the “admin down” devices transition to
“admin up”.
When the devices are in the “admin up” state, the XCO
intended configuration synchronizes with the device configuration.
- Any Tenant CLI or REST API of
delete nature attempted on the target devices having “partial success topology”
results in deconfiguration attempted on the “admin up” devices, and
deconfiguration not attempted on the “admin down” devices. The CLI or REST API
operation fails with an appropriate error indicating that the deconfiguration
not being attempted on the “admin down” devices.
The reason being XCO does not
want to leave stale configurations on the devices because if the stale
configurations are left on the devices, then bringing the devices (having
stale configurations) back into XCO is erroneous considering the full
brownfield support is missing in XCO. You can retry the same CLI or REST API
operation after the “admin down” devices transition to “admin up” state so
that the deconfiguration is attempted on all the devices. You can always use
“force” option available in REST API to forcefully delete the entities from
XCO even in case of partial success topology.
- Drift between the XCO intended
configuration and device config is shown in the efa tenant debug device
drift CLI or REST API output and in the corresponding entity GET
or SHOW output (for example, efa tenant epg show
and efa tenant po
show in the form of “app-state” and “dev-state”.
- XCO blocks the tenant
reconciliation API and rest of the tenant APIs support partial success
behavior.
